Zig 0.16#59955
Conversation
tranzystorekk
force-pushed
the
zig16
branch
2 times, most recently
from
cffb28e to
409129e
Compare
|
Please correct anything I might not have understood about this topic, but per the discussion in #60034... The blog post discussing the changes to river links to another page with a list of WMs that work with the new protocol. Edit: links, verbiage, clarify tinyrwm state |
|
The nature of a rolling distro means this will be a breaking change with an INSTALL.msg announcement displayed during update, but you raise some valid points:
|
|
re: river: I've packaged and tested river with rrwm, but I don't think I'll be using it at this time. My recommendation is:
|
|
Ghostty doesn't build either (neither the old 1.1.3 nor 1.3.1) but they're working on updating everything to zig 0.16 right now: ghostty-org/ghostty#12388 |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
On native |
|
it has one |
|
Yep, it was me doing stupid things. Sorry. |
|
@tranzystorekk |
|
hello, what is blocking this update currently? I see every zig package have to be updated in order to keep repo stable. Is there any package or problem left? Can I help for transitioning to zig 0.16. And how can I test if everything ok in the whole repo with new zig version? |
|
currently, there are at least two open matters:
|
|
ok. I see now. Waiting for 0.17 makes sense. About river, I think finding a default is just become a matter of taste. I have been using beansprout for a couple of months. It covers most of the river-classic features.
these are missing ones in my case. I didn't look differences in default config but I think It is a good option for users. But it also requires zig 0.16 like river itself. Not a problem though. Is your plan really provide featurefull default or let user recover from "miss launching river". By spawning a terminal or closing river? I think if exist, something like kiosk might be enough as a default. |
|
i believe any sensibly working wm would serve as a foot in the door to inspire other people to package more river software, but i'd prefer something not written in zig to make it more independent from the already awful zig situation on void |
|
wideriver does not require zig to compile, i believe. it's been packaged for a couple distros already. |
Isn't wideriver only for river-classic? Since I thought the issue was that there wasn't a packages for river 0.4.0 window managers. |
sorry if that's the case. i thought river-classic had its own window manager. i checked the river website and they don't list wideriver in their window manager list. then tarazed might be a good alternative. |
I concur.. By process of elimination, I tested I know I previously argued in favor of having at least one river 0.4 wm packaged, but I'd like to retract that sentiment. |
rip yorhel
|
One moment, let me check something... https://codeberg.org/ziglang/translate-c/issues/409 seems like I used wrong API? but I never got these errors |
|
So it seems For now I moved to deprecated https://github.com/BratishkaErik/ncdu/releases/tag/v2.10.1-dev.1 |
|
With the old translateC step, it's hard to persuade zig to find the include dir: |
|
Can you try this then: My command worked: PKG_CONFIG="aarch64-unknown-linux-gnu-pkg-config" zig build -fsys=zstd -fsys=ncurses -Dtarget=aarch64-linux-gnu --sysroot /home/bratishkaerik/Projects/ncdu/aarch64-unknown-linux-gnu/ --search-prefix /usr/ --libc aarch64_libc.txtaarch64_libc.txt: include_dir=/home/bratishkaerik/Projects/ncdu/aarch64-unknown-linux-gnu/usr/include
sys_include_dir=/home/bratishkaerik/Projects/ncdu/aarch64-unknown-linux-gnu/usr/include
crt_dir=/home/bratishkaerik/Projects/ncdu/aarch64-unknown-linux-gnu/usr/lib
msvc_lib_dir=
kernel32_lib_dir=
gcc_dir=BTW Zig internally prepends sysroot to search-prefix automatically, so no need to add it in CLI. Or else you get: |
Thought I'd get some results by forcing llvm/lld like river does https://codeberg.org/river/river/src/commit/d4fef528467974b9014b0bc9c47a9ea682cc8d4b/build.zig#L22 |
|
I don't understand the problem. Why not have a separate zig-0.13 version for older apps that require it and update the main package? I can't use the packaged zig on my own projects nor can I package/compile other applications such as fairyglade's ly with 0.13. I don't see why forward compatibility should be sacrificed for so long because of river when it can be maintained differently |
Observing the discussions in the PR, I was wondering exactly the same. For LLVM there is also one package for each major version. Maybe I'm missing something here, that this approach cannot be applied to Zig. Given the fact that there are almost always breaking changes between the major versions still, it sounds to me like the perfect solution. |
|
The current Zig ecosystem in Void land is arguably in a sorry state; we have a handful of packages in various upstream maintenance quality, and the main goal for the I'm against splitting zig into versioned subpackages, as that's a sure way to even more chaos, e.g. when packages eventually start jumping zig versions and the old zig subpackages become obsolete leftovers. This is especially true for toolchains dependent on LLVM such as Zig. On a side note, that makes me very unwilling to accept new zig packages like |
|
https://github.com/BratishkaErik/ncdu/releases/tag/v2.10.1-dev.10 Also I tried to make simple Dockerfile for test: # STAGE 1: THE BUILD ENVIRONMENT (Runs on host architecture, e.g., x86_64)
FROM --platform=$BUILDPLATFORM alpine:3.24 AS builder
WORKDIR /build
ARG SYSROOT="/usr/aarch64-linux-musl"
# 1. Install Zig 0.16.0, and stuff for downloading and unpacking NCDU sources
RUN apk add --no-cache zig git
# 2. Set up cross-target environment
RUN apk add --no-cache \
--initdb \
--root "${SYSROOT}" \
--repositories-file /etc/apk/repositories \
--allow-untrusted \
--arch aarch64 \
musl-dev ncurses-dev zstd-dev
# 3. Download and unpack NCDU sources
RUN git clone --depth=1 https://github.com/BratishkaErik/ncdu /build/ncdu
WORKDIR /build/ncdu
# 4. Generate target-architecture specs file for Zig
RUN cat <<EOF > aarch64_libc.txt
include_dir=${SYSROOT}/usr/include
sys_include_dir=${SYSROOT}/usr/include
crt_dir=${SYSROOT}/usr/lib
msvc_lib_dir=
kernel32_lib_dir=
gcc_dir=
EOF
# 5. Compile NCDU
# NOTE: --sysroot is prepended to --search-prefix value by Zig!
# But not to libc paths above...
RUN zig build \
-fsys=zstd \
-fsys=ncurses \
-Dtarget=aarch64-linux-musl \
--sysroot "${SYSROOT}/" \
--search-prefix /usr \
--libc aarch64_libc.txt \
-Doptimize=ReleaseSafe \
-Dstrip -Dpie
# STAGE 2: AArch64 runtime
# Needs emulation support enabled for containers
FROM --platform=linux/arm64 ghcr.io/void-linux/void-musl:latest
WORKDIR /app
RUN xbps-install -Syu && xbps-install -y \
ncurses \
libzstd \
file
COPY --from=builder /build/ncdu/zig-out/bin/ncdu /app/ncdu
CMD ["/bin/sh"]Running: docker buildx build --load -t ncdu-isolated-test .
docker run --rm -it ncdu-isolated-test 01:13:15
WARNING: The requested image's platform (linux/arm64) does not match the detected host platform (linux/amd64/v4) and no specific platform was requested
# ls
ncdu
# file ncdu
ncdu: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-aarch64.so.1, stripped
# ./ncdu -o json.export
# file json.export
json.export: JSON text data
# cat json.export
[1,2,{"progname":"ncdu","progver":"2.10.1-dev","timestamp":1782245604},
[{"name":"/app","asize":4096,"dsize":4096},
{"name":"json.export"},
{"name":"ncdu","asize":437640,"dsize":438272}]]
#P.S.: Dockerfile should be saved in LF, otherwise https://codeberg.org/ziglang/zig/issues/35906 will appear |
|
Due to the above difficulties, I see no reason why the words of Andrew Kelley should not be included & considered: |
|
I don't see why we can't package separate Zig versions like we do for LLVM. What chaos are you referring to exactly? At least this would address the current problem in void-packages. Older versions don't even need to be maintained and can slowly fade away as projects move onwards with updating their Zig dependency. |
15 participants
Testing the changes